1. Field of the Invention
The invention relates to high capacity digital telecommunications switches which are controlled by a host. More particularly, the invention relates to compatible methods for controlling otherwise incompatible digital telecommunications switches as well as apparatus incorporating the methods.
2. State of the Art
Modern telecommunications systems utilize high capacity digital switching systems to process calls and effect different types of telecommunications. These switches are typically built in a modular form utilizing a bus and a plurality of modular cards which are mounted in racks and slots. A typical switch is the LNX-2000 from Excel, Inc., Sagamore Beach, Mass. Prior art FIG. 1 shows the general physical configuration of the LNX-2000 and prior art FIG. 2 shows a general block circuit diagram illustrating a bus and a plurality of modular cards.
Referring now to FIGS. 1 and 2, the digital switch 10 includes a rack 12 having slots 14a-14t which are associated with a bus 16. Typically, a redundant bus 16a is also provided as a back-up should the bus 16 fail for any reason. The first two slots 14a, 14b are usually reserved for a power supply 18 and a redundant power supply 18a. The last two slots 14s, 14t are usually reserved for a switch matrix CPU 20 and a redundant switch matrix CPU 20a. Each matrix CPU is provided with a respective control link 22, 22a for connection to a host 40. The control links are usually RS-232 serial links Each matrix CPU may also be provided with a reference clock port (not shown). The other slots are provided for modular cards 24, 26, 28, 30, and 32a-k, for example. The cards may provide access telecommunications channels, provide telecommunications signalling, or provide other telecommunications services. For example, card 24 shown in FIG. 2 provides a 192-channel T1 interface Card 26 provides a 256-channel E1 interface. Card 28 provides a 24-channel ISDN Primary Rate interface. Card 30 provides digital signal processing such as tone generation, tone reception, digital voice recording and playback, etc. It will be appreciated that some of the interface cards will rely on functions of other cards in order to execute certain telecommunications functions. In general, each of the cards will rely on the matrix CPU for intelligent control of their basic functions. In addition, the T1 interfaces and the E1 interfaces may cooperate to provide conversions. The ISDN interfaces will rely on the T1 or E1 interfaces for B channel access. The DSP cards may be called upon by all of the interface cards to generate appropriate signalling tones.
Each of the cards in switch 10 is typically configured to operate in a user definable manner. Configuration of the cards is effected by the host 40 which sends configuration data to the matrix CPU 20 (20a) which in turn remembers the configuration data for each card in the switch. In addition, the matrix CPU contains system software which is downloaded to it by the host. The system software governs the basic switch operation. Call processing activities are controlled by the host which remains in communication with the matrix CPU so long as the switch is in service.
Typical switch configuration commands issued by the host to the switch (the matrix CPU) include: resetting line cards, changing the service state of a card (placing it in and out of service), resetting the matrix CPU, downloading system software to the matrix CPU, setting the system time, system network synchronization, assigning logical span IDs, changing a channel service state, changing a channel configuration, changing a trunk type configuration (defining the signalling protocol for a particular channel or group of channels), changing a start dialing signalling protocol, configuring timers and filters (for signalling), busying out trunks, setting answer supervision mode(for each channel), setting release modes for a channel, setting call setup inpulsing parameters. Once configured, the switch remains configured until a card or the matrix CPU is reset, or until a change in service dictates changing one or more of the configuration parameters. For example, if new trunks are added or new cards are added, additional configuration will be required. Usually, the configuration data is saved as a file by the host and downloaded to the matrix CPU together with system software if the switch is reset.
Typical ongoing communication between the switch (the matrix CPU) and the host includes call processing, control of tone generation and reception, and call progress analysis. Call processing relates to how the switch handles incoming and outgoing calls and includes the functions of call setup, cross connections, inseize/outseize call control, incoming call setup, inseize control instructions, outgoing call setup, outseize control instructions and connection management. Tone generation control includes defining tone specifications, tone detection, digit collection, tone generation, outpulsing setup, and generating tones for prompting and call status information (e.g. dial tones and busy signals). Call progress analysis is generally used when originating a call to the PSTN and includes the functions of invoking the analysis, designing the analysis, configuring global parameters and cadence pattern parameters, setting pattern defaults and pattern ID5 and setting class and tone group defaults.
The LNX 2000 Switch provides a host messaging protocol and specific message formats for communication between a host and the switch. Other switches provide their own host messaging protocols which deal with similar activities but which have different message formats. Thus, a host must be programmed in one way to control one brand of switch and in a different way to control another brand of switch. That is, different switches use different hardware components and therefore respond to different message sets. For example, the Summa 4 SDS Series of switches includes a Network Bus Controller Card, a Bus Repeater Card, a Direct Inward Dial Card, an EandN Trunk Card, a Subscriber Line Interface Card, a Universal Trunk Card, a Digital Conference Card, among others. These cards require different messages for configuration and operation than the coards mentioned above with regard to the LNX 2000 Switch. Moreover, the SDS Series utilizes its own Unix-based command language which is different from the command language used by the LNK 2000 Switch.
Parent application Ser. No. 08/555,040 discloses an object oriented development system for the configuration of telecommunications equipment including one or more digital telecommunications switches. FIG. 3 illustrates a graphical representation of the structure of the development system. The development system includes an object server 50 having at least one man/machine interface (MMI) agent 52, an object server 54 with predefined managed objects 56 and a database management library 58, a server applications programmer interface (API) 60 coupled to the MMI and the object server for hiding the internal architecture of the object services from the MMI agent with respect to the managed objects 56, and means for permitting the developer to create and define user-defined managed objects 57 which utilize the database management library and the database which stores managed object related data, and which does not require the server API to be rewritten. The server applications programmer interface (API) is organized and designed in a manner such that the user defined objects are automatically supported by the API. Predefined managed objects are initialized at start-up before the initialization of the user-defined objects. The development environment allows for the rapid development and deployment of new telecommunications services using combinations of predefined managed objects and user defined managed objects. The managed objects can include hardware such as shelf, rack, board, switch, signalling, etc., service software such as call processing triggers and features, configuration software such as rule group and alarm, and user defined objects. As shown in FIG. 3, a hardware object 56a is provided to interface with a high speed digital switch so that applications developed in the system 50 can act as a host to the switch. As mentioned above, however, switches from different manufacturers communicate using different protocols. This makes object definition more complicated because the switch signalling and supervision messages of the API of the system 50 must be rewritten to accommodate the protocol of different switches.
It is therefore an object of the invention to provide a method by which a single API can be used to control a number of switches having different message protocols.
It is also an object of the invention to provide modular switching engines for use with an object oriented development system for the configuration of telecommunications equipment including one or more digital telecommunications switches.
It is another object of the invention to provide an object oriented development system for the configuration of telecommunications equipment including one or more digital telecommunications switches which includes a number of switching engines so that a number of switches utilizing different messaging protocols can be controlled from a single API.
It is still another object of the invention to provide methods and apparatus whereby a single host computer can be used to control a plurality of different switches, each switch having a different messaging protocol.
In accord with these objects which will be discussed in detail below, the methods of the present invention include providing a xe2x80x9cgenericxe2x80x9d switch messaging protocol for message handling and switch supervision and providing a number of switching engines, each of which is conversant with the generic messaging protocol, each switching engine also being conversant with a specific switch messaging protocol. The apparatus according to the invention includes an object oriented development system utilizing a xe2x80x9cgenericxe2x80x9d switch messaging protocol and a plurality of switching engines, each of which is conversant with the generic messaging protocol and each of which is conversant with a specific switch messaging protocol. According to the invention, certain switch messages are not xe2x80x9cgenericizedxe2x80x9d because their functionality is different from the functionality of other switches. These messages generally include initialization and maintenance messages which are hardware specific and have no counterpart in another switch from a different vendor. In order to handle these messages, specific data files are provided in the switching engine for automatic download to the switch as well as a specific NML for interpreting configuration commands. Also, according to the invention, some commands or messages which are not otherwise supported by a particular switch can nevertheless be supported in the API by providing the switch engine with the intelligence to combine native switch messages to xe2x80x9cemulatexe2x80x9d a functionality which is not directly provided by the switch.
Additional objects and advantages of the invention will become apparent to those skilled in the art upon reference to the detailed description taken in conjunction with the provided figures.